Since its invention, public-key cryptography techniques have been increasingly used to protect communications. In a typical scenario, a system of devices communicate over a network to exchange data between the devices. The network may be defined by dedicated telecommunication lines, or by a restricted access network within an organisation or by a public network accessible to all. The communication links of the network may be established by hard-wired connections or may be wireless or may be a combination of such links. Such networks are frequently used to transfer sensitive confidential information; and some adversaries external to the system may try to subvert or compromise the system by masquerading as a system entity, manipulating system messages, obtaining the secrets of one or more existing entities, etc. Public key cryptography involves assigning to each system entity secret data, called a ‘private key’ and corresponding public data, called a ‘public key’ which can be used to help secure communicated messages. Entities may have several such sets of keys for use in various techniques and for various purposes.
Many public-key cryptographic techniques can be employed to protect messages. For example, the sender of a message can create a digital signature on a message. A recipient of the message and the associated digital signature can use the public key of the sender and the digital signature to authenticate the message and to detect modification of the message by an adversary. This verification process requires the public key of the sender, so the recipient should be assured of the authenticity of the sender's public key before relying on the result of the verification. Digital signatures also provide for non-repudiation of messages, meaning the signor cannot subsequently disclaim the signature, which is important in some systems.
Having assurance that a given public key is authentic is important for cryptographic procedures other than digital signature verification. For example, before encrypting a message to a user “Alice”, using Alice's (presumed) public key, and a corresponding public key encryption protocol, the sender should ensure that the public key is an authentic copy of Alice's public key (and not, for example, a public key created by an adversary trying to masquerade as Alice).
The same is true if, instead of encrypting a message to Alice, a shared key is established through a key-agreement protocol with her. Key-agreement protocols allow a sender and a recipient to establish a shared key using the private key of one entity and the public key of the other entity. The sender can then encrypt (using fast symmetric-key protocols) a message so that it is intelligible only to the intended receiver. Again, the authenticity of the recipient's public key is critical to the security of this process.
In large systems it is not always feasible for every device to store the public key of every other device, so when system entities want to communicate with each other using public key protocols, they must somehow obtain authentic copies of each other's public keys. If system entities agree to trust a distinguished system entity known as a Certificate Authority (CA), this problem of obtaining authentic public keys can be solved using Digital Certificates. The primary role of the CA is in specifying the current members of the system at any given time. To do this the CA issues Digital Certificates to system entities. Digital Certificates are documents, signed by the CA, that bind an identified system identity to a particular public key, so that the public key associated with that identity can be authentically determined. The document to be signed, usually referred to as the pre-signature or to-be-signed certificate, will often include additional information, such as a certificate serial number, the validity period of the certificate, e.g. time of issue and time of expiry, and supplementary information identifying the protocols and parameters to be used. When the information is assembled, the CA signs it. The to-be-signed certificate along with its signature is referred to as the end-entity certificate, or simply certificate. In very large systems the CA may delegate this work to sub-certificate authorities (also referred to as delegates or deputies), who will be identified as such in their certificates.
In such systems every entity has an authentic copy of the public key of the CA and so can verify signatures created by the CA. Hence when a system entity receives a certificate from another system entity they can use the CA public key to verify the CA's signature and thereby verify the authenticity of the public key contained in it. Thus the CA's digital signatures, used to create entity certificates in this manner, solves the problem of distributing authentic public keys to other system entities.
In such a system, an entity identified as Alice, say, can send a message M to other system entities, and they can be assured that a received message claimed to be from Alice did actually originate from her. A typical protocol would have Alice digitally sign a message M to create signature sig_A. The signature sig_A is generated using Alice's private key corresponding to her public key, Pub_A, whose authenticity is assured by a certificate, Cert_A, issued by the CA binding Alice's identity to her public key. Alice may send [M, sig_A, Cert_A] to her peers. Her peers use Cert_A and the Certificate Authority public key and predefined computations and logic encoded in the hardware or software of their device to confirm that the public key Pub_A contained in Cert_A is considered valid for use and is indeed Alice's.
If Alice's public key is considered valid for use, the message M, the signature, Sig_A, and this public key Pub_A, are processed by predefined rules and logic encoded in the hardware or software of the peer device to determine if the signature, Sig_A, is valid. If the signature is valid, the message is interpreted as truly coming from Alice. Similarly, in other cryptographic protocols requiring authenticity of public keys, such as public key encryption or key-exchange, entity certificates can be used as part of the protocol to establish authenticity of entity public keys.
A problem in systems of the above type is that the adversary may be capable of compromising a system entity, say Alice, to varying degrees. For example an adversary may be capable of tricking Alice into signing messages in a way that is detrimental to the rest of the system. Or perhaps the adversary is capable of determining Alice's private key and can therefore forge perfect versions of Alice's signature on arbitrary messages.
Once a compromised individual like Alice is detected, a CA has the option of declaring Alice a non-member of the system by ‘revoking’ her certificate. The process by which the CA typically revokes Alice's certificate may involve the use of a Certificate Revocation List, or CRL. A CRL is another type of structured document signed by the CA. The normal structure is, for example, a list of serial numbers, some bits indicating one or more predefined conditions apply to the serial number in question, a date or version and possibly other identifying information about the CRL itself, and a signature on the document by the Certificate Authority or another entity authorized to sign a CRL. The CA revokes Alice's certificate by listing her certificate's serial number on a CRL issued by the CA. Systems using CRLs for revocation often include, as part of the predefined process for checking authenticity of a certificate, a phase where the serial number of the certificate in question is confirmed to not be listed in the most current CRL available.
CRLs may offer limited control. Initially, a system entity has a private key and associated certificate and has not had its certificate revoked. In this case messages signed by the entity will be accepted as valid by an entity provided they pass the predefined checks embodied in each entity's logic, and provided the entity's certificate has not been listed on a CRL obtained by the validating entity. Once a system entity is revoked no message henceforth created by the entity should be accepted by the system.
Validating entities are encouraged to frequently obtain updated versions of the system CRL. In some cases the CRL may be transmitted to the system entities, but more typically, the CRL is made available to system entities for individual queries. The checking of the CRL requires the entity to review the entire list of revoked certificates to ensure that the certificate received is not on the list. Maintenance of the list may also be complex, particularly when an entity can have more than one certificate, or when the certificates of a group of entities have to be revoked. In that case, it is necessary to identify each of the certificates and ensure the serial number of each is listed on the next CRL issued by the CA.
Another existing method of determining whether the certificate associated with an entity is valid is as follows. The CA or another authorized entity operates a service, such as the Online Certificate Status Protocol (OCSP) in which entities in the process of validating a message can query the service about the revocation status of a given certificate. In some OCSP services, called ‘OCSP stapling’, an entity can use the service to obtain a time stamped message from the CA or another authorized entity stating that their certificate is unrevoked, which can then be attached and forwarded along with the certificate. In each case system entities are in direct two-way communication with the CA or its deputies.
A simple but representative example of a method for protecting system messages in the above framework is as follows. Suppose a company manufactures autonomous surveillance drones. During manufacturing, these drones obtain a private key and an associated certificate issued by the CA. In addition, the drones are installed with predefined hardware or software logic that protects and validates messages between system entities. On receipt of an incoming communication that will include a message, such as data indicating a new surveillance target for a drone, a digital signature of that message by the sender, and the certificate issued by the CA that authenticates the public key of the presumed sender of the message, the predefined software or hardware logic in the drone verifies the digital signature on the message using the public key in the certificate, and also determines whether the certificate contains a valid signature using the CA's public key, and that the certificate has not expired. The drone may itself try to obtain a recent CRL or one may be provided in the received communication. If a CRL is available the predefined logic verifies the CA's signature on the CRL and also checks whether the received certificate has been listed as revoked in the CRL. There may be some other predefined checks in the process of validating a chain of certificates such as, for example, confirming that policy identifiers in the received certificate conform to a predetermined value that distinguishes the drone system from other systems that the CA may administer. Such predetermined checks can become quite complicated as they often embody policy decisions about the system, which can become more complicated as the system grows.
For a number of reasons it may be difficult to modify the predefined hardware or software logic in a drone once it has left the manufacturing line. Reasons can include the need for specialized tools, the fact that the drone may be operational and regulatory or safety requirements may prevent such modifications during an operational phase, or the fact that such modifications may require the physical replacement of logic parts embodied in ROM or other hardware. In such situations the methods of protecting system messages are restricted to only those techniques considered up to the point of manufacture of the drone. These difficulties in updating control software (or hardware) are not restricted to the case of drones, but apply in many other situations where code and systems are difficult to update, owing to the fact that these have been subject to certification or audit, are critical safety systems which have undergone extensive validation and should not be changed, or due to the technology used to implement these control systems, which may have components in ROM or other technology which is difficult to change in the field.
A common complaint about current systems of this sort is their complexity, in particular with regards to the parsing and interpretation of the various certificate information in the process of validating a certificate chain for a large system. Moreover, using CRLs typically add significant overhead to the processing of communications, adding significantly to the maintenance of the communication system. In spite of the overhead introduced by using them, traditional CRLs are relatively inflexible in their ability to describe the conditions under which a certificate may be revoked. Also CRLs are used to help determine whether a given certificate is to be considered valid, where in general entities of the system should actually be concerned about whether the inbound communications as a whole, and in particular if the underlying message should be considered valid. In addition to basic policy decisions which concern the validity of certificates and the messaging protected by digital signatures associated with these certificates, the update of any policy in fielded equipment is currently difficult, especially in those cases where underlying components have been certified or highly tested and validated, or where the technology used to implement these policies is somewhat inflexible.
It is therefore an object of the following to address and/or mitigate the above disadvantages.